\chapter{Skalowalność rozwiązania}
\label{chap:etap2-skalowalnosc}

Ważną częścią projektu jest skalowalność rozwiązania. Dzięki zastosowanej architekturze  cały system jest bardzo dobrze
skalowalny. Istotny jest fakt, iż zastosowanie odpowiedniej architektury i~technologii powoduje, iż w~trakcie tworzenia kodu
aplikacji nie ma potrzeby tworzenia specjalnych fragmentów zwiększających skalowalność. Oczywiście nadal konieczne jest myślenie
o skalowalności i odpowiednie wykorzystanie możliwości. Możemy wyodrębnić trzy aspekty skalowalności: serwer aplikacji klienckiej,
bazy danych i serwera aplikacji.

\subsubsection{Serwer aplikacji klienckiej}

Klient w postaci statycznej strony www może być udostępniany przez
prosty serwer http.

Brak dynamicznego generowania strony powoduje, że obciążenie tego serwera nawet przy dużym ruchu będzie minimalne. Użycie serwera nginx, lighttpd powinno zapewnić wystarczającą wydajność. Oba serwery\footnote{\burl{http://wiki.nginx.org/Main}}\footnote{\burl{http://redmine.lighttpd.net/projects/lighttpd/wiki/DevelProblemAndSolution}} są blisko związane z~rozwiązaniem problemu c10k\footnote{\burl{http://www.kegel.com/c10k.html}} (10000 równoległych połączeń), zatem obciążenie do 10000 użytkowników nie powinno być problemem.

Dodatkowo do dostarczenia klientowi zewnętrznej biblioteki jQuery można wykorzystać ogólnodostępne CDN\footnote{\burl{http://docs.jquery.com/Downloading_jQuery\#CDN_Hosted_jQuery}}.

\subsubsection{Baza danych}
Twórcy Neo4j zapewniają o~skalowalności swojego rozwiązania\footnote{Co wspomniane było w poprzednim etapie projektu.} a Spring Data Graph wspiera wykorzystanie funkcjonalności High Availability. Z~tego powodu ograniczeni jesteśmy jedynie jakością dostarczonego nam rozwiązania.

\subsubsection{Serwer aplikacji}
Zamierzamy użyć \mbox{Apache Tomcat 7}, który jest znanym i~szeroko stosowanym rozwiązaniem. Rozwiązanie to można skalować uruchamiając np.~na klastrze. Umożliwia to między innymi:
\begin{itemize}
\item balansowanie obciążenia,
\item wykorzystanie kilku słabszych maszyn w miejscu jednej dużej,
\item odporność na awarie.
\end{itemize}

Dodatkowo z~uwagi na charakter aplikacji, skalowanie jest bardzo
łatwe. Składa się na to kilka czynników.

Po pierwsze, dane użytkowników nie są zapisywane do bazy danych, zatem można wyobrazić sobie N~serwerów aplikacji każdy połączony z własną bazą danych. Jedynie w~trakcie aktualizacji rozkładu ważne jest zachowanie spójności. Do rozkładania ruchu można wykorzystać Apache Tomcat Connector\footnote{\burl{http://tomcat.apache.org/connectors-doc/index.html}}.

Istotny jest też fakt, że zapytanie jest bezstanowe, zatem nie ma potrzeby przenoszenia danych sesji między serwerami.


\subsubsection{Podsumowanie}
Biorąc pod uwagę wszystkie wymienione aspekty problemu, łatwo zauważyć iż dzięki odpowiedniemu rozwiązaniu
architektury i wykorzystaniu odpowiednich technologi, system jest
skalowalny, jednocześnie nie obciążając programistów tworzeniem kodu
odpowiedzialnego za tą możliwość.
